Add infallible primitive type lookups to template arg resolver by Walnut356 · Pull Request #157289 · rust-lang/rust

Walnut356 · 2026-06-02T07:58:44Z

Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. Vec<i32>) to fail to create their child values.

Before:

(lldb) v vec_v
(alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {}
(lldb) v vec_v[0]
error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v"
   1 | vec_v[0]
     | ^

After:

(lldb) v vec_v
(alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {
  [0] = 10
  [1] = 20
  [2] = 30
  [3] = 40
  [4] = 50
}
(lldb) v vec_v[0]
(long) vec_v[0] = 10

This patch maps the type name to its eBasicType equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, eBasicType lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, TypeSystemClang will invent the appropriate SBType object for it.

This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21.

r? @jieyouxu, @Kobzol

rustbot · 2026-06-02T07:58:49Z

jieyouxu is not on the review rotation at the moment.
They may take a while to respond.

jieyouxu

Thanks, this indeed improves the output for me locally (msvc, lldb 22).

Test case

Used a tiny test case

//@ compile-flags: -g
//@ lldb-command: run
//@ lldb-command: v vec_0
//@ lldb-check: [...] vec_0 { }
//@ lldb-command: continue

fn main() {
    let vec_0 = vec![1, 2, 3];
    vec_0; // #break
}

I do indeed observe the fixed ouput 👍

v vec_0
(alloc::vec::Vec<i32,alloc::alloc::Global>) vec_0 = size=3 { [0] = 1 [1] = 2 [2] = 3 }

Other remarks

Looks like the package change meant that lldb_batchmode/runner.py need to update the path in which breakpoint_callback is referenced (as discussed),

diff --git a/src/etc/lldb_batchmode/runner.py b/src/etc/lldb_batchmode/runner.py
index e9b106390f6..bdeee3f3458 100644
--- a/src/etc/lldb_batchmode/runner.py
+++ b/src/etc/lldb_batchmode/runner.py
@@ -98,7 +98,7 @@ def execute_command(command_interpreter, command):
                     "registering breakpoint callback, id = " + str(breakpoint_id)
                 )
                 callback_command = f"breakpoint command add -s python {str(breakpoint_id)} -o \
-                    'import lldb_batchmode; lldb_batchmode.breakpoint_callback'"
+                    'import lldb_batchmode; lldb_batchmode.runner.breakpoint_callback'"

                 command_interpreter.HandleCommand(callback_command, res)
                 if res.Succeeded():

We can just roll this into this PR, you can r=me after.

View changes since this review

jieyouxu · 2026-06-06T07:29:31Z

@rustbot author

rustbot · 2026-06-06T07:29:34Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

jieyouxu

Thanks!

I confirm this achieves It Works On My Machine™️ status

@bors r+ rollup

View changes since this review

rust-bors · 2026-06-06T07:59:15Z

📌 Commit bde0008 has been approved by jieyouxu

It is now in the queue for this repository.

rust-bors · 2026-06-06T08:04:49Z

This pull request was unapproved due to being closed.

jieyouxu · 2026-06-06T08:05:13Z

@bors r+

rust-bors · 2026-06-06T08:05:15Z

📌 Commit bde0008 has been approved by jieyouxu

It is now in the queue for this repository.

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

Walnut356 · 2026-06-06T15:24:43Z

should be good now, just gated the import behind a feature flag.

Kobzol · 2026-06-06T16:25:16Z

@bors try jobs=aarch64-apple

Add infallible primitive type lookups to template arg resolver try-job: aarch64-apple

rust-bors · 2026-06-06T19:08:36Z

☀️ Try build successful (CI)
Build commit: 1254eb0 (1254eb0c9c84b5a07df90159025acc3002590958, parent: 8954863c81df429ebf96ea38a16c76f209995833)

jieyouxu · 2026-06-07T06:44:13Z

@bors r+

rust-bors · 2026-06-07T06:44:16Z

📌 Commit c6945a5 has been approved by jieyouxu

It is now in the queue for this repository.

jieyouxu · 2026-06-07T07:21:52Z

@bors rollup=iffy

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

…uwer Rollup of 10 pull requests Successful merges: - #157447 (Move cross crate tests into the appropriate folder) - #145108 (Resolver: Batched Import Resolution) - #156119 (Further optimize `SliceIndex<str>` impl for `Range<usize>`) - #157289 (Add infallible primitive type lookups to template arg resolver) - #157540 (Cleanup and optimize `render_impls`) - #157543 (Reorganize `tests/ui/issues` [5/N]) - #156188 (riscv: promote d, e, and f target_features to CfgStableToggleUnstable) - #157323 (Document Repeat::last panic behavior) - #157545 (Suggest using comma to separate valid attribute list items) - #157559 (chore: Update annotate-snippets to 0.12.16)

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

@jieyouxu

…eyouxu Add infallible primitive type lookups to template arg resolver Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values. Before: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {} (lldb) v vec_v[0] error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v" 1 | vec_v[0] | ^ ``` After: ``` (lldb) v vec_v (alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 { [0] = 10 [1] = 20 [2] = 30 [3] = 40 [4] = 50 } (lldb) v vec_v[0] (long) vec_v[0] = 10 ``` This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it. This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21. r? @jieyouxu, @Kobzol

Rollup of 25 pull requests Successful merges: - #157447 (Move cross crate tests into the appropriate folder) - #145108 (Resolver: Batched Import Resolution) - #156119 (Further optimize `SliceIndex<str>` impl for `Range<usize>`) - #157224 (Manually unroll loop in `str::floor_char_boundary`) - #157289 (Add infallible primitive type lookups to template arg resolver) - #157540 (Cleanup and optimize `render_impls`) - #157444 (Couple of work product cleanups) - #157543 (Reorganize `tests/ui/issues` [5/N]) - #153513 (Syntactically reject equality predicates) - #155797 (LineWriter: cap write_vectored newline scan to avoid quadratic write_all_vectored) - #156155 (macros: report unbound metavariables directly) - #156188 (riscv: promote d, e, and f target_features to CfgStableToggleUnstable) - #156666 (Clarify meaning of ranges in pointer offset docs) - #157078 (Document equivalence of `highest_one` and `ilog2` methods on integers) - #157129 (ci: update download-artifact action to v8) - #157169 (triagebot: Update messages to direct changes to appropriate repositories) - #157323 (Document Repeat::last panic behavior) - #157370 (Clarify MaybeUninit::zeroed padding docs) - #157399 (Silence llbc's output by default to prevent rustc's linker output warning) - #157500 (Improve documentation of `align_of` and `Alignment`.) - #157545 (Suggest using comma to separate valid attribute list items) - #157559 (chore: Update annotate-snippets to 0.12.16) - #157560 (In `copy_nonoverlapping`, use `mul nuw nsw` to compute the byte size) - #157580 (Importing suggestion reported twice when reporting privacy error) - #157581 (Test fixup)

Rollup of 25 pull requests Successful merges: - rust-lang/rust#157447 (Move cross crate tests into the appropriate folder) - rust-lang/rust#145108 (Resolver: Batched Import Resolution) - rust-lang/rust#156119 (Further optimize `SliceIndex<str>` impl for `Range<usize>`) - rust-lang/rust#157224 (Manually unroll loop in `str::floor_char_boundary`) - rust-lang/rust#157289 (Add infallible primitive type lookups to template arg resolver) - rust-lang/rust#157540 (Cleanup and optimize `render_impls`) - rust-lang/rust#157444 (Couple of work product cleanups) - rust-lang/rust#157543 (Reorganize `tests/ui/issues` [5/N]) - rust-lang/rust#153513 (Syntactically reject equality predicates) - rust-lang/rust#155797 (LineWriter: cap write_vectored newline scan to avoid quadratic write_all_vectored) - rust-lang/rust#156155 (macros: report unbound metavariables directly) - rust-lang/rust#156188 (riscv: promote d, e, and f target_features to CfgStableToggleUnstable) - rust-lang/rust#156666 (Clarify meaning of ranges in pointer offset docs) - rust-lang/rust#157078 (Document equivalence of `highest_one` and `ilog2` methods on integers) - rust-lang/rust#157129 (ci: update download-artifact action to v8) - rust-lang/rust#157169 (triagebot: Update messages to direct changes to appropriate repositories) - rust-lang/rust#157323 (Document Repeat::last panic behavior) - rust-lang/rust#157370 (Clarify MaybeUninit::zeroed padding docs) - rust-lang/rust#157399 (Silence llbc's output by default to prevent rustc's linker output warning) - rust-lang/rust#157500 (Improve documentation of `align_of` and `Alignment`.) - rust-lang/rust#157545 (Suggest using comma to separate valid attribute list items) - rust-lang/rust#157559 (chore: Update annotate-snippets to 0.12.16) - rust-lang/rust#157560 (In `copy_nonoverlapping`, use `mul nuw nsw` to compute the byte size) - rust-lang/rust#157580 (Importing suggestion reported twice when reporting privacy error) - rust-lang/rust#157581 (Test fixup)

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 2, 2026

rustbot assigned jieyouxu Jun 2, 2026

Kobzol reviewed Jun 2, 2026

View reviewed changes

Comment thread src/etc/lldb_providers.py

jieyouxu added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-debuggers-lldb Area: lldb and removed A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) labels Jun 3, 2026

jieyouxu reviewed Jun 6, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 6, 2026

jieyouxu approved these changes Jun 6, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 6, 2026

This comment has been minimized.

Sign in to view

jieyouxu closed this Jun 6, 2026

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 6, 2026

jieyouxu reopened this Jun 6, 2026

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 6, 2026

jieyouxu mentioned this pull request Jun 6, 2026

Update MSVC LLDB 22 advice rust-lang/rustc-dev-guide#2895

Merged

Walnut356 force-pushed the msvc_template_args branch from bde0008 to c6945a5 Compare June 6, 2026 15:24

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jun 6, 2026

Auto merge of #157289 - Walnut356:msvc_template_args, r=<try>

1254eb0

Add infallible primitive type lookups to template arg resolver try-job: aarch64-apple

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 7, 2026

JonathanBrouwer mentioned this pull request Jun 7, 2026

Rollup of 6 pull requests #157564

Closed

JonathanBrouwer mentioned this pull request Jun 7, 2026

Rollup of 11 pull requests #157569

Closed

JonathanBrouwer mentioned this pull request Jun 7, 2026

Rollup of 10 pull requests #157570

Closed

JonathanBrouwer mentioned this pull request Jun 7, 2026

Rollup of 21 pull requests #157582

Closed

This was referenced Jun 7, 2026

Rollup of 21 pull requests #157583

Closed

Rollup of 25 pull requests #157586

Merged

rust-bors Bot merged commit b5fcf78 into rust-lang:main Jun 8, 2026
13 checks passed

rustbot added this to the 1.98.0 milestone Jun 8, 2026

Uh oh!

Conversation

Walnut356 commented Jun 2, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 2, 2026

Uh oh!

Uh oh!

jieyouxu left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Test case

Other remarks

Uh oh!

jieyouxu commented Jun 6, 2026

Uh oh!

rustbot commented Jun 6, 2026

Uh oh!

jieyouxu left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Jun 6, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 6, 2026

Uh oh!

jieyouxu commented Jun 6, 2026

Uh oh!

rust-bors Bot commented Jun 6, 2026

Uh oh!

Walnut356 commented Jun 6, 2026

Uh oh!

Kobzol commented Jun 6, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 6, 2026

Uh oh!

jieyouxu commented Jun 7, 2026

Uh oh!

rust-bors Bot commented Jun 7, 2026

Uh oh!

jieyouxu commented Jun 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Walnut356 commented Jun 2, 2026 •

edited by rustbot

Loading

jieyouxu left a comment •

edited

Loading

jieyouxu left a comment •

edited by rustbot

Loading